Difference Between DATETIME, TIMESTAMP, and CONVERT_TZ()
MySQL stores time zone–aware data differently depending on whether you use DATETIME, TIMESTAMP, or CONVERT_TZ(). Each serves specific use cases based on time zone handling and storage behavior.
Stores a date and time exactly as entered, without any time zone conversion.
Does not track or adjust time zones internally.
Suitable when you want to store local time values exactly as they occur.
Common for scheduling events, logs, or timestamps where local meaning is fixed.
Stored internally in UTC, but automatically converted to the session's time zone for display.
Converts from session time zone → UTC on insert, and UTC → session time zone on select.
Automatically affected by daylight savings and time zone changes.
Ideal for global applications requiring consistent and comparable time values.
Used to manually convert a DATETIME or TIMESTAMP from one time zone to another.
Does not change the stored value; only transforms it in the query result.
Depends on MySQL time zone tables being loaded.
Useful when you need explicit control over source and target time zones.
DATETIME stores values as-is with no automatic time zone handling.
TIMESTAMP stores values in UTC and converts automatically for users.
CONVERT_TZ() is used for manual time zone adjustments in queries.
Use DATETIME for local-event-based data, TIMESTAMP for universal logging, and CONVERT_TZ() for custom conversions.